1. Field of the Invention
The present invention relates generally to graphical objects. More particularly, some example embodiments relate to rendering, connecting, and manipulating complex graphical objects.
2. Related Technology
Existing techniques for drawing, displaying, and/or manipulating graphical objects in web applications using native browser functionality are slow. This is seen when objects move on/across the screen or when users interact with graphical objects.
Typically, the entire working area that the user sees is redrawn every time an object moves. This is due to the existing implementations of native browser drawing capabilities. In the case of the HTML5 canvas element, the entire drawing area is a single raster device, and must be redrawn from scratch on most changes. In the case of SVG (scalable vector graphics), even the simplest changes to the markup representing the final object display can require the browser to “re-flow” and re-render the entire scene.
Hence, the responsiveness of graphical applications delivered in a browser is often poor, frequently resulting in a visual latency or lag that causes a poor user experience. Alternatively, instead of giving users a real-time dynamic view of what changes will look like, many web based applications only provide a limited representation of tentative changes being made before the change is committed. For example, when a user clicks on an object and drags it with a mouse to move it, many applications will only show an outline or shadow of the object move along with the user's mouse cursor; it is only when the user releases the click (to confirm the move) that the object—and the page—is redrawn with the object in its new location and the rest of the page updated accordingly.
As a result, many “rich internet applications” delivered over the web make use of non-native browser technologies, such as browser plugins, e.g., Flash, Java or Silverlight, that make use of precompiled code running on virtual machines to allow rendering of and interaction with graphic elements. With plugins such as Flash, however, each time a change is made in code, the code must be re-compiled into a .swf (“Small Web Format” or “ShockWave Flash”) file and uploaded to the server. The end-user must consequently re-download the entire application binary. These technologies also limit the deployment of the application to those platforms that support the required plugin.
Building on a proprietary plugin like Flash also restricts applications from using standard form controls that are common in web sites and web applications. This makes the whole user experience of Flash applications significantly different from that of other web applications, which can cause frustration and confusion for users.
Allowing other developers to create extensions for an application is difficult with Flash and similar technologies due to their closed, compiled nature. In addition, generating graphical output that is consistent across different browsers or different file types is difficult. For example, different browsers use different rendering techniques for graphics—Internet Explorer uses VML, whereas many other browsers support Canvas—so that building applications that present a consistent output across different browsers is difficult. The main challenge is that different output devices, such as different browsers, file formats, or image generation libraries, implement different subsets of common rendering functionality. Furthermore, outputting what the user sees in the browser to different file formats (such as vector PDF, for printing, or image formats such as PNG) in a consistent manner so that what is seen in the browser is the same as the PDF/PNG is also challenging.
The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one exemplary technology area where some embodiments described herein may be practiced